The present invention relates to a system for determining the software inventory and usage on a computer and, more particularly, to a system and method for consolidating and reducing software usage data to evolve information about software inventory as well as usage.
A software monitoring and auditing system (SMAS) is used to first determine the inventory of software products (including relevant identifying information) and their component modules that are installed on one or more computer systems or a complex or Sysplex of such systems. Secondly, an SMAS is used to determine the modules, products, and versions and releases of products that are actually being used. An SMAS (such as Isogon's, the present Assignee's, SoftAudit product) is typically used in large computing environments, such as mainframes, and must gather and process vast amounts of data. Aspects of Isogon's SoftAudit product are described in U.S. Pat. No. 5,499,340, the contents of which are incorporated by reference herein.
A typical mainframe computer might have 500 products, composed of 500,000 modules on 3,000 libraries, often with many of the products duplicated on a number of libraries. As such, inventory data, consisting of a record for every module installed on every library on the computer system, will often times reflect half a million to several million modules.
Such computing environments are not static. Inventories must be redone periodically, perhaps weekly or monthly, to detect changes, such as new modules or deleted modules. Often, rather than the most current inventory data replacing all prior data, it must be kept in addition to all prior data in order to accurately reflect inventory over time.
Usage data is typically gathered by use of a monitoring program designed specifically for that task, by a capability inherently included within the operating system, or a combination of both. Collectively, this process is called the Monitor. The data consists of information reflecting the execution of some or every module in the system. Such data may include the module name, the library or directory it resides on, date and time of use, the process (such as job step) using the module, the user ID associated with that process, and so on. In some instances, the Monitor may construct a fingerprint, pattern, calculation, or other module analysis that results in a characteristic of the executing module that can be used to identify that module when correlated to similar data contained within the module inventory. In mainframe systems, many millions of modules may be executed each day, and it is usually desirable or necessary to retain the usage data pertaining to an extended time period, for example the most recent three or six months.
An SMAS typically processes the inventory data using predetermined rules and heuristics against a knowledge base (KB) 10 that correlates identifying module characteristics of software modules 12a, 12b . . . 12n with software products 14a, 14b (FIG. 1) in order to determine the software product (and optionally the version and release of that product) that each module belongs to. Module characteristics may include the module name, fingerprint, pattern, calculation, or other characteristic as the result of a module analysis. The SMAS may also apply rules such as “the product name is incorporated into the name of the library or directory the module is located.”
The resultant product-identified inventory may be stored in a separate database or incorporated into the knowledge base.
The SMAS also correlates usage data against the KB or against the product-identified inventory data to determine what product each executed module belongs to.
Through such processing, an SMAS is able to provide users with information organized in a number of different views, such as:                module inventory, by system, by library        product inventory, by system, by library        module usage, by time period, by system, by library        product usage, by time period, by system, by library        product usage, by product version and release, by time period, by system, by library        product usage, by time period, by system, by library, by user ID        product usage, by product version and release, by time period, by system, by library, by user ID        product usage, by time period, by user ID, by system, by library        product usage, by product version and release, by time period, by user ID, by system, by library        user activity, by time period, by product, by system        product usage by job or job-step        user activity, by product, by time period, by system        
While usage data is generated on computer systems that are the subject of the auditing activity, it is often desirable to allow the users of an SMAS to review the data, including the above views, on a desktop PC, separate and apart from the one where the auditing activity takes place. One approach to achieving this is to simply transfer the usage data, as it is collected or periodically, to a personal computer. Another approach is to provide remote access to this data from a PC. But because of the extreme volume of data, these approaches may not be practical—it may take too long to transfer (if done electronically, by downloading), or may take up more disk memory than is available on the PC, or may represent more data than can practically be processed on a desktop computer. Moreover, the overhead and duration of performing the necessary processing and analysis of the gathered usage data, whether the processing is done on a PC or a mainframe, is proportional to the quantity of data processed, and can often be burdensome.